Zum Hauptinhalt springen

LLM oder hard-coded?

Das ist die wichtigste Entscheidung beim Aufbau eines Workflows — und gleichzeitig die, bei der Einsteiger am häufigsten in die falsche Richtung gehen.

Der Generative AI Agent ist mächtig und vielseitig. Er kann Texte analysieren, Daten extrahieren, Entscheidungen treffen, umformulieren, zusammenfassen. Es liegt nahe, ihn für alles einzusetzen. Das ist ein Fehler.

Warum LLMs keine Rechenmaschinen sind​

Ein LLM (Large Language Model) ist ein Wahrscheinlichkeitsmodell. Es erzeugt Ausgaben die mit hoher Wahrscheinlichkeit korrekt sind — aber eben nur mit hoher Wahrscheinlichkeit, nicht mit Sicherheit. Das ist der fundamentale Unterschied zu hard-coded Logik:

  • Hard-coded: 2 + 2 ergibt immer 4. Ohne Ausnahme. Kein Rauschen, keine Varianz.
  • LLM: Ein Modell das gebeten wird 2 + 2 zu berechnen, wird fast immer 4 antworten — aber "fast immer" ist nicht dasselbe wie "immer".

Für Konversation, Interpretation und das Arbeiten mit unstrukturierten Daten ist diese Eigenschaft akzeptabel. Für deterministische Logik — zählen, filtern, sortieren, formatieren — ist sie ein unnötiges Fehlerrisiko.

Die Entscheidungsregel​

Eine einfache Faustregel deckt die meisten Fälle ab:

Ist die Datenbasis unstrukturiert oder kenne ich ihre Struktur nicht im Voraus — LLM. Sonst hard-coded.

SituationEmpfehlung
Struktur der Eingabe ist bekannt und vorhersagbarHard-coded
Eingabe ist immer gleich aufgebautHard-coded
Zählen, Filtern, Aggregieren, SortierenHard-coded
Formatieren von Daten mit bekannter StrukturHard-coded
Text mit unbekannter Struktur analysierenLLM
Informationen aus Freitext extrahierenLLM
Kategorisieren wenn Kategorien aus dem Inhalt folgenLLM
Zusammenfassen, umformulieren, erklärenLLM

Konkrete Beispiele​

Hard-coded — nicht promten​

Einträge zählen Du hast ein JSON-Array mit Bestellungen und willst wissen wie viele es sind. Das ist ein Array-Length-Aufruf in JavaScript — eine Zeile Code, null Fehlerwahrscheinlichkeit. Einen LLM zu fragen "wie viele Einträge hat dieses Array?" wäre teurer, langsamer und unzuverlässiger.

Bestimmtes Feld aus JSON extrahieren Du weißt dass dein Webhook immer {"order_id": "...", "customer": "..."} liefert. message.order_id per JavaScript oder Liquid Template ist die richtige Antwort — nicht ein LLM-Aufruf.

Datum formatieren Von 2026-03-10 zu 10.03.2026 — das macht ein Message Formatting Agent oder ein JavaScript Agent in einer Zeile.

JSON strukturieren Wenn du weißt wie der Input aussieht und wie der Output aussehen soll, ist das ein JavaScript-Mapping. Kein LLM nötig.

LLM — weil hard-coded nicht ausreicht​

Rechnungsnummer in Freitext finden Eine Rechnung liegt als PDF-Text vor. Du weißt nicht wie der Lieferant die Rechnungsnummer beschriftet — manche schreiben "Rechnungs-Nr.", andere "Re.-Nr.", andere "Invoice No." oder gar nichts. Ein LLM erkennt das zuverlässig. Ein Regex würde alle nicht vorhergesehenen Varianten übersehen.

Dokumenttyp bestimmen Ein eingescanntes Dokument soll als "Rechnung", "Lieferschein" oder "Mahnung" kategorisiert werden. Die Entscheidung basiert auf dem Inhalt — das ist eine klassische LLM-Aufgabe.

Freitext-Feedback auswerten Kundenkommentare in strukturierte Kategorien überführen — positiv/negativ/neutral, Thema, Dringlichkeit. Die Eingabe ist per Definition unstrukturiert.

Ein Praxisbeispiel: Log-Verarbeitung komplett hard-coded​

Dieses Beispiel zeigt wie weit man mit hard-coded Logik kommt — und dass man für Datenverarbeitung mit bekannter Struktur überhaupt kein LLM braucht.

Aufgabe: Log-Dateien einer Maschine einlesen, in eine Datenbank schreiben und täglich einen strukturierten Schichtbericht erstellen.

Schritt 1: Log-String in JSON überführen (JavaScript Agent)​

Die Log-Datei kommt als Rohtext. Die Struktur ist zeilenbasiert und bekannt — Datum, Uhrzeit, Level, Quelle, Info. Ein JavaScript Agent parst das:

// Jede Zeile in ein strukturiertes Objekt überführen
const lines = input.log_content.split('\n').filter(l => l.trim());
const entries = lines.map(line => {
  const parts = line.split(/\s+/);
  return {
    date: parts[0],
    time: parts[1],
    level: parts[2],
    source: parts[3],
    info: parts.slice(4).join(' ')
  };
});
return { log_entries: entries };

Kein LLM — die Struktur ist bekannt, JavaScript ist deterministisch.

Schritt 2: Einträge in Internal Storage schreiben (JSON Split + Internal Storage Agent)​

INSERT INTO logs
  (log_entry_id, log_date, log_time, level, source, info, reported_state, created_at, updated_at)
VALUES
  ('{{ log_date }}-{{ log_time }}-{{ source }}',
   '{{ log_date }}', '{{ log_time }}', '{{ level }}', '{{ source }}', '{{ info }}',
   'unreported', datetime('now'), datetime('now'))

Liquid Templating setzt die Werte aus der Nachricht ein — kein LLM.

Schritt 3: Schichtbericht erstellen (SQL + Message Formatting Agent)​

Drei parallele Internal Storage Agents — einer pro Schicht, jeder mit einem eigenen Zeitfenster im SQL — aggregieren die Einträge:

SELECT
    level,
    source,
    info,
    COUNT(*) AS anzahl,
    MIN(log_date || 'T' || log_time) AS erstes_auftreten,
    MAX(log_date || 'T' || log_time) AS letztes_auftreten
FROM logs
WHERE
    (log_date || 'T' || log_time) >= '{{ schicht_start }}'
    AND
    (log_date || 'T' || log_time) <= '{{ schicht_ende }}'
GROUP BY level, source, info
ORDER BY anzahl DESC

Das Ergebnis wird per Message Formatting Agent in eine Markdown-Tabelle überführt — ebenfalls hard-coded mit Liquid-Schleifen.

Kein einziger LLM-Aufruf im gesamten Workflow. Die Struktur der Log-Dateien ist bekannt, die Aggregationslogik ist deterministisch, die Ausgabe ist definiert. Hard-coded ist hier die richtige Wahl.

Die Kostenperspektive​

LLM-Aufrufe sind langsamer und teurer als JavaScript, SQL oder Message Formatting. Jeder unnötige LLM-Aufruf verlängert die Laufzeit eines Workflows und erhöht die Last auf dem Modell-Server. In Workflows die tausende Male täglich laufen, summiert sich das erheblich.

Hard-coded Logik ist nicht nur zuverlässiger — sie ist auch schneller und ressourcenschonender.

Zusammenfassung​

Setze LLMs ein wenn du sie wirklich brauchst: für unstrukturierte Eingaben, für Interpretation, für Kategorisierung ohne feste Regeln. Für alles andere — SQL, JavaScript, Message Formatting, JSON Parse, Liquid Templates — ist hard-coded Logik die überlegene Wahl: zuverlässiger, schneller, günstiger und leichter zu debuggen.

Erkennungszeichen für unnötige LLM-Nutzung

Wenn du einen Generative AI Agent verwendest und den Prompt mit exakten Feldnamen, festen Formaten oder konkreten Rechenanweisungen füllst — dann ist das ein Hinweis dass die Aufgabe besser hard-coded gelöst werden sollte.